Repository navigation
Conversation
Zend/zend_execute.c:zend_verify_arg_type() enforces some type hints: - wrong object class (assumes an implied type hint to IS_OBJECT) - not an array - not a callable - disallowed nullness for the previous cases - for any other type hints, raise an error Those hints are used in the Reflection API (currently only in __toString as there is no getter). Zend/zend_API.c:zend_parse_arg_impl() uses a provided format string and performs automatic convertion if possible. The zend_verify_arg_type() function is called by the Zend VM at some low level. As PHP wants more flexibility, it should not enforce type hinting much. Hence, I left the current rules, but removed the last one that raises an error for non object, array or callable types. As a consequence, ARG_INFOs of PHP_FE can now be more precise and helpful.
Type hinting is an available information in ReflectionParameter, however it is only used in __toString()! Made that information available through the getTypeHint() function, which returns the string representation of the type hint constant. Turned ReflectionParameter::export() and __construct() to use ZEND_ARG_TYPE_INFO() instead of ZEND_ARG_INFO(), in order to register the actual type hinting. Added a test to ensure getTypeHint() works fine with type hinted function and returns NULL for non type hinted ones. See request #45569, the second part.
|
I don't like the idea of adding this without the corresponding userland type hinting support. If that would be added in the future then you could easily get problems because old extension code relies on scalar typehints to not do anything. |
|
Scalar typehints imply an automatic convertion too, but not exactly in the same place. The only thing the first commit prevents, is extensions to declare uncallable functions by using scalar typehints. |
|
Comment on behalf of lstrojny at php.net: While I would like to see this change merged, I think having a short RFC (https://wiki.php.net/rfc/voting) would be the right thing to do here as it might be a massive change. From my POV the RFC should discuss:
Thanks! |
Master pins the engine to Mago 0.3.0, 58c7c4a. This branch needs the Set checker and lowering, which Mago PR #101 carries, so the merge pins its head, b68a9c4. That head refuses `Set.from` in PHP# code, keys a Set by its backing type for external analyzers, and takes the master fixes #105 and #107. The header Mago generates at that head differs only in this pin, so `SHARP_UNIT_ABI` is unchanged. ext/sharp/ sharp_unit.h SHARP_MAGO_COMMIT is b68a9c4
3 participants
All extensions use
ZEND_ARG_INFO,ZEND_ARG_OBJ_INFOorZEND_ARG_ARRAY_INFO, but none useZEND_ARG_TYPE_INFO, because of a bug.The advantage of using the latter over the primer is that it permits giving a type hint to PHP.
The only impact of a type hint should be visible in the Reflection extension, as it merely is a hint.
However Zend emits a bug systematically if the type info is given:
PHP Fatal error: Unknown typehint in file.php on line 1.The first commit fixes this bug, enabling widespread use of
ZEND_ARG_TYPE_INFO.Currently only
ReflectionParameter::__toString()permits getting back this information inside a PHP script, forcing ugly string analysis to get it back.The second commit makes the type hint information accessible through the
ReflectionParameter::getTypeHint()method, which returns, likegettype(), the string representation of the given type hint, or NULL if none is provided (yet).